The rapid evolution of computer and communication technologies coupled with the robust economies of the 1980s and 1990s resulted in unprecedented growth in the information technology (or “IT”) field. During this period, the need to establish a competitive advantage drove companies to faster and faster rates of change to support new product offerings and expanded services. As a result of these market pressures and time constraints, most companies elected to support new products and services by adding additional back office systems. However, due to the lack of mature integration technologies, the new systems were connected to the existing IT systems by making direct connections to the software routines already in use. The vulnerability of this design is that a change in one system produces a “ripple effect” change in every system it connects with. Over time, this incremental stacking of software systems can result in an integration ceiling. That is, at a certain point, more effort is spent on the connections than on new functionality and further expansion becomes cost prohibitive.
In the late 1990s, new integration technologies emerged that made it possible to “loosely couple” applications so that systems are no longer directly connected. Thus, changes in one system would not cause a ripple effect in any other systems. The most notable of these technologies are Message Oriented Middleware (or “MOM”), Publish and Subscribe messaging, and Object Request Brokers (or “ORBs”). These technologies enabled companies to re-architect their conglomeration of systems into an architecture that allows them to expand in a cost-effective manner. Technologies such as these that address the problem of integrating existing systems with new systems in an organized, efficient, and economically scaleable manner can be referred to collectively as enterprise application integration (or “EAI”) technologies.
An integrated enterprise may have any number of applications which interact with one or more shared databases (also referred to as an integrated information store (or “IIS”)) of the integrated enterprise through a data access layer (or “DAL”). Among other things, interface control documents (or “ICDs”) for an integrated enterprise describes all of the application-to-database operations taking place within the integrated enterprise. An interaction with a database of an integrated enterprise is typically in the form of an interface definition language (or “IDL”) “call”. More specifically, an IDL call is comprised of a first (or “logical operation name”) portion, a second (or “logical data aggregate name”) portion and a third (or “data attribute”) portion. The logical operation name portion of the call describes the type of application-database operation to be conducted, the logical data aggregate name portion of the call describes the name of the data to which the operation is applied and the data attribute portion of the call is comprised of one or more data attributes, each of which describes a discrete characteristic of the data involved in the application-database operation.
Application-database operations may be divided into two types of operations—those that produce data and those that consume data. As defined herein, data producing operations are those operations which involve data being written to a database. Data consuming operations, on the other hand, are herein defined as those operations which involve data being read from a database. Many problems in application-database operations arise when a system designer fails to ensure that a correspondence exists between the data produced and the data consumed. In other words, application-database operations which involve consuming data which was never produced (hereafter referred to as a “producer exception”) or producing data which is never consumed (hereafter referred to as a “consumer exception”) should be avoided. Of the two, the former is a more serious problem. Since data cannot be consumed before it is produced, a producer exception causes an error in the system. Conversely, while a consumer exception does not cause a system error, since there is no reason to produce data which is never consumed, a consumer exception unnecessarily wastes system resources.
Errors such as these can only be identified through a detailed manual examination of the ICD documents which model an enterprise. Such a task can, however, be quite difficult. In U.S. patent application Ser. No. 10/286,526 filed Nov. 1, 2002 and previously incorporated by reference, we disclosed a tool capable of identifying exceptions in database operations contained within an analysis model of an enterprise based upon an examination of the usage of data attributes in the database operations. However, as it is a tool for analyzing the analysis model of an enterprise, the aforementioned tool can only examine application-database operations between the various applications and the DAL—the logical interface to the IIS. By limiting the examination of the model in this manner, however, any number of inconsistencies in the model may be missed. For example, a single data attribute may be mapped to multiple fields in the physical databases which collectively form the IIS. Conversely, a single field in one of the physical databases may be mapped to multiple data attributes. Finally, a data attribute may not be mapped to a physical database at all. It is, therefore, the object of this invention to provide a tool capable of identifying these or other exceptions in physical database operations contained within a design model of an enterprise.